当我们讨论开源的时候，我们在讨论什么
近日朋友圈刷屏了关于《faker.js开源作者删除所有代码》的相关贴子，甚至平时不关注开源的一些从事开发工作的朋友也都纷纷表达了自己的看法，主要声音还是对于开源前景的唱衰以及开源理念与现状之间矛盾的怀疑和否定。
无可厚非，这次“删库跑路”事件之所以能够火出圈，引起大家对于开源本身的热议，可能还是“个人开发者苦大公司久矣”的滥觞……
首先回到本次争议焦点的项目本身，faker.js是一个著名的node.js工具库，作者Marak前前后后耗费了十余年来完成和维护这个开源项目确实值得钦佩。
faker.js最重要的功能是制造许多不同类型的假数据，可用于数据分析中的开发调试等场景，因此包括Google在内的很多头部公司也在使用。
但作为优秀开源项目的作者，Marak的实际生活过得并不顺利，甚至可以用窘迫来形容，这就更加剧了与项目本身热度的强烈对比，也引发了社区众多开发者对此遭遇的同情和对于免费使用这一开源项目而赚得盆满钵满的大公司的抗议。
社区开发群体的情绪固然可以理解，但对于开源理念和社区现状本身的争议不是本文讨论的焦点，本文撰写的目的主要是就开源许可证本身和许可证的选择适用作一些探讨。
笔者访问了GitHub上的项目地址，在项目详情页里确实已经“人去库空”了。而通过作者Marak进行检索发现，除了本次争议项目faker.js之外，Marak还拥有另一比较有热度的开源项目colors.js，而对其许可证核查之后可以看到，其使用的许可证与前述项目相同，也是“The MIT License”。
作为OSI（Open Source Initiativ,开放源代码促进会）官方认证的最为宽松的开源许可证协议之一，MIT可以说是比较“佛系”的了。其除了最为基础的版权合规声明披露之外，基本可以说是没有任何附加限制，可完全放开使用甚至闭源商用。
MIT许可证条款权利义务梳理[1]
开源许可证并非一成不变
开源的代码从法律客体上属于开发者本身的软件作品，天然受著作权的保护。而作为开发者即原始著作权人，在开源本项目的时候选择某一License，也就是拟定了一份针对不特定相对人的格式合同，不同的许可证在权利授予、保留和附带义务的声明条款之间存在差别自然就是对于著作权人自身和使用开源项目的相对人的不同程度和角度的约束。
Marak当初为faker.js和color.js项目选择了MIT License，而后的时间里，虽然从项目的历史issue记录里可以看到其早就对于这一现状有种种不满，但不知出于何种考量，其并未对后续项目版本的许可证作出变更，自然无法从“法律规则”这一玩法上做出有效的实际诉求。
许可证本质上就是著作权人针对所完成作品的版权条款，当发布新的软件版本时，自然就属于新的作品，不用再受此前版本签订的许可协议的约束，而是可以选择新的许可协议来“另起炉灶”对使用新软件版本和补丁的相对人进行新的约束，从而最大化符合自身的开源诉求。
这种操作屡见不鲜，当年MongoDB“忍无可忍”就选择了这一做法。原因就是一些云服务提供商使用其开源代码并向用户提供云端的商业数据库版本，在违反GNU AGPLv3协议的边缘疯狂试探，甚至直接违反了协议。
MongoDB对于这种“使用开源软件不劳而获，却又吝于反馈社群促进技术进步共享”的行为很生气，后果就是宣布其开源许可证从GNU AGPLv3切换到Server Side Public License (SSPL)。新许可证将适用于新版本的MongoDB Community Server以及打过补丁的旧版本。
开放源代码+许可证协议限制≠开源软件+开源许可证
其实对于一个开源项目和背后的技术主体，如何选择一份合适的许可证来满足自身的利益诉求和项目发展壮大的需要，本就是一个复杂且需要平衡和取舍的事情。选择一份适合新开源项目的许可证，不仅对于缺乏开源项目运营经验的个人开发者来说是一道大命题，据笔者接触和了解到的，即便是一些拥有开源治理经验和运营成绩的知名大公司，在面对这一问题时，最终的选择也往往是多方考量的过程和结果。
这里就不得不提到OSI（Open Source Initiativ,开放源代码促进会）了。作为推动开源软件发展的非盈利组织，其对于开源许可证的知名“十大定义”——The Open Source Definition[2]，成为了一大批想要获得其官方认证背书的许可协议的拦路虎。
诸如NVIDIA的“End User License Agreement”，在制定之初就压根没考虑成为“开源许可证”，只是作为分发其旗下产品CUDA Toolkit时的约束条款；再比如一向对于开源比较保守的Intel，当年还曾积极拥抱过开源社区，“The Intel Open Source License for CDSA/CSSM Implementation”选择了“BSD许可证+例外Export Notice”的条款，但后期由于自身发展的需要，无法同时满足OSI的认证标准和自身利益诉求，也只能与“开源许可证”含泪分手，“retired”了这一许可证而转为制定自家的商业许可协议。
作为经过OSI认证和开发者社区时间检验的开源许可证，目前数量上已经超过100种可供开源项目的主体选择。作为个人开发者和中小型主体，可以在开源项目之前审慎明确自己的利益诉求挑选适合自己的许可协议（可添加例外声明来满足自身要求，或者实在不行还可以在项目发展过程中变更许可证嘛，但要注意自身是否拥有独立的著作权基础，避免权利瑕疵），作为有较大技术影响力的技术主体，也可以尝试在现有许可协议基础上拟定自己的许可协议，甚至在制定之后评估是否符合OSI的认证标准，从而向OSI申请认证，使自己的许可协议成为官方背书的新开源许可证。
要不要开源，自己说了算
除了对开源许可证选择的讨论，跳出开源回到最开始的问题，开源一个项目（准确来说是开放一个项目的源代码）给不特定公众，允许其使用和二次开发的时候，究竟是为了什么？
和仅提供功能接口的闭源软件包不同，开放源代码必然意味着把一部分技术秘密公之于众，那接下来怎么办？
对于个人开发者或者公司而言，首先要明白自身的核心竞争力到底是什么？
项目是亲生的孩子，维护项目就是抚养孩子的过程。
如果构建的代码本身是核心竞争力和技术壁垒，那么谨慎选择开源。开源项目就相当于把孩子从家里扔到了社区，如果在别人contribute的精心哺育下孩子和他人越来越亲近，甚至他人看不惯你教育孩子的方式而另行fork了新的分支后成长得更好，那这个孩子长大后还跟不跟你姓就不一定了；
如果代码本身不是核心壁垒，即使开放给公众之后，仍有足够信心从其它渠道找到生财之路来满足自身的利益诉求（例如提供维护服务等渠道收到钱，好比相信自己能够做个好父母，能够解决孩子成长阶段面临的种种问题；或者像Google一样通过开源Android，让产业链上所有的手机厂商，都可以无缝内置基于安卓的GMS，从而实现了垄断移动端流量，从而为进一步实现“流量-搜索-广告-变现”这一步骤提供了坚实基础），那么就可以考虑选择一个合适自身利益诉求的开源许可证来发布开源项目。
开源or商业？小孩子才做选择
众所周知，开源有风险。更因为免费才最贵，所以“白嫖需谨慎”。很多人了解这一点，一些有技术实力的厂商更了解这一点，所以一条新的道路出现了：开源+商业双许可模式。
如MySQL分为企业版和社区版。其中MySQL社区版是全球广受欢迎的开源数据库，可以免费使用。它遵循GPL（GNU General Public License）开源许可协议，由庞大、活跃的开源开发人员社区提供源代码以及相应的技术支持，任何人均可以免费使用MySQL并且可以对其进行代码修改。
但由于GPL族许可证的“强传染性”，很多不想公开其源代码的厂商用户望而却步，MySQL正是基于这一出发点构建了商业授权许可（企业版）。
而这一切操作之所以可行，都是因为Oracle拥有著作权，因此不管是GPL还是商业授权，都是版权所有者对其他人设置约束规则。
其官网声明如下：
搞清定位+选好方向+摆正心态
以上内容对于开源应当考虑的因素和许可证的选择方式做了一些最为基础的思考供探讨。而面对如今天faker.js作者怒而删库而引发的社区动乱，以及开源项目的开发者和使用者之间收益回报的争论，作为有开源潜在诉求的开发者群体，能从中学到的唯一确定的点，就是搞清定位+选好方向+摆正心态。
想清楚要不要开源？再思考怎么开源？还要明白开源就是取舍，有舍才有得。以BSD、MIT为代表的宽松型许可证和GPL族为代表的严格型许可证，都是在取舍之间选择了不同的诉求，而都有各自的代表性开源项目获得成功。
因此与其说开源与否看似是一道选择题，不如说是一道主观辨析题，项目的开发者就是答题者，如何做好这份答卷，需要更深入全面的思考，也需要审慎下笔。
RECOMMEND
推荐阅读
2022-01-13
2022-01-11
2022-01-07
2022-01-06
看世界
欢迎原创投稿，稿件一经采用，支付稿费
投稿邮箱：iptree@iptalent.com
看都看了，点个“在看”再走鸭